iT邦幫忙

2023 iThome 鐵人賽

DAY 3
0
SideProject30

手速太慢?打造自己的下單 APP系列 第 3

【鐵人賽】DAY-03 初探 protobuf、gRPC

  • 分享至 

  • xImage
  •  

IMG

本文同步發佈於毛毛的踩坑人生

前言

昨天,我們有提到預計會將整個框架拆分成兩個後端、一個前端
並且後端跟後端之間是採用 gRPC 的方式溝通
應該是目前跨平台所使用的大多數微服務採用的方案
要使用這個技術
那就得先提到 ProtobufgRPC
但我們會從動機開始談

動機

說到 API 的溝通媒介
我想大家第一時間還是會想起 JSON
作為一個跨 process 的溝通格式,而且也是人類可讀
也被廣泛使用了很長一段時間
優缺點也是很明顯,Protobuf 也強力問世
下面我們來比較一下兩者

JSON

優點

  1. 易於讀寫和理解: JSON 使用人類可讀的格式,易於閱讀和手動編輯。

  2. 簡單性: JSON 是一種輕量級的數據交換格式,不需要額外的工具或庫就可以解析和生成。

  3. 廣泛支援: JSON 被幾乎所有編程語言支援,可以輕鬆地在不同環境中使用。

缺點

  1. 效能較差: JSON 效能較 Protobuf 差,因為它的文本格式需要解析和序列化的時間較長。

  2. 佔用空間大: JSON 使用文本格式,佔用的空間比二進制格式(如 Protobuf)多,導致較大的數據大小。

  3. 沒有類型信息: JSON 缺乏類型信息,需要額外的邏輯來處理數據的類型和校驗。

Protobuf

優點

  1. 高效的二進制格式: Protobuf 使用二進制編碼,比 JSON 更節省空間,並且解析/序列化速度更快。

  2. 強大的類型系統: Protobuf 定義了嚴格的數據類型和結構,可以提供更好的數據校驗和保護。

  3. 自動生成程式碼: Protobuf 可以從定義文件自動生成程式碼,減少了手動編碼的工作量。

  4. 跨平台和語言支援: Protobuf 支援多種編程語言,可以在不同平台上使用,並提供了良好的互操作性。

缺點

  1. 不易讀寫: Protobuf 使用二進制編碼,對於人來說不易讀寫,需要工具來解析和編輯。

  2. 不易調試: 由於二進制格式,難以手動檢查和調試數據,特別是在測試和除錯時可能較為困難。

  3. 版本兼容性: 在數據結構變更時,可能需要複雜的版本處理和升級策略,以確保舊版本和新版本的兼容性。

小小總結一下

  • 效能方面,在程式交易的範疇下,高效的 Protobuf 勝🥇

  • 強類型部分,可以在開發階段少掉很多冤枉路 Protobuf 勝🥇

  • 人類可讀性的部分,以我自己的觀點,只要錯誤處理得當,不可讀並不能算缺點

編譯器

決定使用 Protobuf 後,第一件事就是安裝編譯器
這個編譯器將會負責將同一份 protobuf,編譯成不同的程式語言
這次框架使用到的 Python, Golang, Flutter 全部有被支持

安裝

可以到這個 Github 找到自己平台的 Release 來安裝
這邊提供一份,我常用的安裝腳本

version="24.3"
curl -fSL https://github.com/protocolbuffers/protobuf/releases/download/v$version/protoc-$version-osx-aarch_64.zip --output protoc.zip
rm -rf ~/sdk_tools/protoc
mkdir -p ~/sdk_tools/protoc
echo "Unzipping protoc.zip..."
unzip -q protoc.zip -d ~/sdk_tools/protoc
chmod +x ~/sdk_tools/protoc/bin/protoc
rm -rf protoc.zip

然後更新一下環境變數
將以下加入 ~/.bashrc or ~/.zashrc

export PATH="$HOME/sdk_tools/protoc/bin:$PATH"

$protoc --version
libprotoc 24.3

能夠看到版本,就沒有問題

定義 Proto

這邊將會使用最新的 proto3
我先舉一個最基本的例子,在未來的篇幅會依據當時的進度加入新的 proto file

下面用一個期貨單的明細當作範例

syntax            = "proto3";
option go_package = "./pb";
package toc_python_forwarder;

message FutureOrderDetail {
    string code    = 1;
    double price   = 2;
    int64 quantity = 3;
}

來說明一下,上面這段

  1. syntax = "proto3";:這一行指定了使用 Proto3 語法,表明這個文件使用 Proto3 版本的 Protocol Buffers

  2. option go_package = "./pb";:這一行指定了生成的 Golang package 名稱

  3. message FutureOrderDetail:在 Protobuf 中會使用 message 當作宣告一個結構的開頭

  4. string code = 1;double price = 2;int64 quantity = 3;:這些行定義了 FutureOrderDetail 消息的字段。每個字段都有一個名稱、類型和唯一的編號。在這個例子中,我們定義了三個:

    • code 是一個 string,編號為 1。

    • price 是一個 float,編號為 2。

    • quantity 是一個 int64,編號為 3。

特別要注意編號在一個結構當中,必須是個唯一值

資料結構

這邊分享一下比較常見的結構,如下圖

.
├── README.md
└── protos
    └── v3
        ├── app
        │   └── app.proto
        └── forwarder
            ├── basic.proto
            ├── entity.proto
            ├── history.proto
            ├── mq.proto
            ├── realtime.proto
            ├── subscribe.proto
            └── trade.proto

編譯

我們把剛剛那個專案資料夾先命名為 trade-protobuf
並且執行位置在這個資料夾的外面一層

Python

剛剛忘記了 Python 這邊,我會使用 Python 的 grpcio-tools 來取代 protoc
原因是到 gRPC 的編譯時,protoc 會缺少一些依賴,所幸我就用 python 原生的編譯器

$pip3 install -U \
  --no-warn-script-location \
  --no-cache-dir \
  grpcio \
  grpcio-tools

$outpath=./src/pb
$python3 -m grpc_tools.protoc \
  --python_out=$outpath \
  --grpc_python_out=$outpath \
  --mypy_out=$outpath \
  --proto_path=./trade-protobuf/protos/v3/app \
  --proto_path=./trade-protobuf/protos/v3/forwarder \
  ./trade-protobuf/protos/v3/*/*.proto

Golang

protoc \
    --go_out=. \
    --go-grpc_out=. \
    --proto_path=./trade-protobuf/protos/v3/app \
    --proto_path=./trade-protobuf/protos/v3/forwarder \
    ./trade-protobuf/protos/v3/*/*.proto

Flutter

protoc \
    --dart_out=./lib/pb \
    --proto_path=./trade-protobuf/protos/v3/app  \
    ./trade-protobuf/protos/v3/app/app.proto

總結

今天大略講述了我在 Protobuf 中的了解
以及如何編譯,接下來會繼續來到 gRPC
一步一步進入到核心的邏輯


上一篇
【鐵人賽】DAY-02 從架構圖開始
下一篇
【鐵人賽】DAY-04 初探 protobuf、gRPC 『二』
系列文
手速太慢?打造自己的下單 APP30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言